home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001247_daemon _Fri Jun 11 01:14:02 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA07100; Fri, 11 Jun 93 01:14:04 MET DST
  3. Return-Path: <montulli@stat1.cc.ukans.edu>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA07096; Fri, 11 Jun 93 01:14:02 MET DST
  6. Received: from stat1.cc.ukans.edu by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA25543; Fri, 11 Jun 1993 01:36:00 +0200
  8. Received: by stat1.cc.ukans.edu (AIX 3.2/UCB 5.64/4.03)
  9.           id AA17132; Thu, 10 Jun 1993 18:28:38 -0500
  10. From: montulli@stat1.cc.ukans.edu (Lou Montulli)
  11. Message-Id: <9306102328.AA17132@stat1.cc.ukans.edu>
  12. Subject: <TITLE>Current Server Work at O'Reilly....</TITLE> (fwd)
  13. To: www-talk@nxoc01.cern.ch
  14. Date: Thu, 10 Jun 93 18:28:38 CDT
  15. X-Mailer: ELM [version 2.3 PL2]
  16.  
  17. > 
  18. >     The theory here is that documents can be rewritten 'on the fly' to
  19. > reference only those capabilities which the user has at hand.
  20. > 
  21. >     Further assume that I have a method of managing documents locally which 
  22. > return portions of a document based on capability metrics.
  23. > 
  24. >     For example:
  25. > 
  26. >     I am a user, using Lynx on a VTxxx.  When I make a request to the 
  27. > server, Lynx also sends:
  28. > 
  29. >         User_Agent: Lynx 1.06 TEXT MAIL NEWS
  30. > 
  31. > since these are the capabilities which Lynx running on my host supports.
  32. > 
  33. >     The server then retrieves the following document
  34. > 
  35. > ------------------------------------------------------------------------------
  36. > <HTML>
  37. > <HEAD>
  38. > <TITLE>This is a document</TITLE>
  39. > </HEAD>
  40. > <BODY>
  41. > 
  42. > #ifdef GRAPHICS
  43. > 
  44. > #    ifdef GIF
  45. > 
  46. >     <IMG HREF=(some gif file)>
  47. > 
  48. > #    elif JPG
  49. > 
  50. >     <IMG HREF=(some jpg file)>
  51. > 
  52. > #    endif
  53. > 
  54. > #else
  55. >     There is an inline graphic here which cannot be rendered 
  56. >     locally.  It can be retrieved by hand as:
  57. > 
  58. > #    ifdef FTP
  59. > 
  60. >     ftp://hostname/dir/file
  61. > 
  62. > #    elif MAIL
  63. > 
  64. >     "/dir/file" from hostname
  65. > 
  66. >     by using the the ftp->mail gateway at Hostname with the 
  67. >     following commands:
  68. >         Get blahblahblahblahblah
  69. > #    endif
  70. > 
  71. > 
  72. > #endif
  73. > 
  74. > </BODY>
  75. > </HTML>
  76.  
  77.  
  78. I don't think that this would be a good way of accomplishing your goals.
  79. The ".multi" extension used to serve documents of varying types would
  80. be a better approach to the problem.   If a link <img src="dinosaur.multi">
  81. was used the client would attempt to retrieve it telling the server
  82. what types it can handle.  In the Lynx case it would say it could handle
  83. ".txt" types and could recieve a text description of the image in question.
  84. Xmosaic would respond with ".gif" and ".xbm" types and would receive the
  85. image.  Other browsers may choose to download the picture and use an 
  86. external viewer to show the image and put a text box in to show where
  87. the picture should have appeared.  If an acceptable type is not available
  88. then the client should respond with an appropriate message explaining
  89. the problem, and pointing out that an image should have appeared "here".
  90.  
  91. I have been meaning to make Lynx image "aware" but have not had the 
  92. time to do so yet.
  93.  
  94. :lou 
  95. montulli@ukanaix.cc.ukans.edu